A distributed transaction is a transaction including operations that are performed by multiple nodes, often implemented at multiple networked computer systems. Distributed transactions arise in a number of different contexts. For example, processing an employee's paycheck may involve a distributed transaction with operations performed by nodes at a number of individual computer systems. An employer payroll system node may request a transfer from its own account to the account of the employee. A node at the employer's bank may debit the employer's account by the amount of the transfer. A node at the employee's bank may credit the employee's account by the amount of the transfer. In another example, booking travel may involve a distributed transaction. A travel agent system node may request reservations on various flights, hotels, etc. In response to the requests, one or more airline system nodes may book flight tickets for a traveler. One or more hotel system nodes may create reservations for the traveler, etc.
In distributed transactions, it is desirable to satisfy the properties of Atomicity, Consistency, Isolation and Durability, known commonly as ACID properties. A distributed transaction satisfying the Atomicity property either successfully executes to completion or fails completely. Referring to the paycheck example, if the employer's bank system crashes or otherwise fails to debit the employer's account, Atomicity would require that the bank system be prevented from completing the transfer to the employee's account. A transaction meeting the Consistency property does not violate integrity constraints of any shared objects. The Isolation property requires that intermediate effects of the transaction are not detectable to concurrent transactions. The Durability property requires that changes to shared objects due to the transaction are permanent.
To ensure the Atomicity property, all participants of the distributed transaction coordinate their actions so that they either unanimously abort or unanimously commit to the transaction. For example, a transaction manager node (e.g., a coordinator node) may enforce Atomicity by coordinating a distributed transaction according to an atomic commit protocol. Atomic commit protocols typically have multiple phases. In a first phase, commonly known as a prepare phase, the coordinator node asks all other nodes participating in the transaction whether they will commit to the transaction. Nodes commit to the transaction by obtaining appropriate locks for transaction objects, executing a transaction operation or operations, and holding the object locks until the coordinator node either completes or aborts the transaction. In a subsequent phase, the transaction coordinator determines whether all transaction nodes have committed. If all nodes have committed, then the transaction coordinator completes the transaction, allowing the nodes to release their locks. If the transaction is aborted, the participating transaction nodes reverse their operations and then release their locks. Accordingly, Atomicity is satisfied because all of the transaction operations are either completed, or not completed.
Some distributed transactions do not always satisfy Atomicity. For example, according to a compensation transaction, participating transaction nodes execute their operation or operations and release their locks before it is known whether the distributed transaction has succeeded or failed. A compensation action is generated for each participating transaction node. If the distributed transaction fails (e.g., if one of the participating transaction nodes cannot execute its operation or operations), then the coordinator node instructs any participating transaction nodes that have already executed operations to “undo” the operations by executing their compensation action.